Along with the wide applications of packet data services, how to accurately and reasonably perform charging to the packet data services has been a problem concerned by operators.
FIG. 1 illustrates a process of performing activation, data transfer and deactivation of a Packet Data Protocol Context (PDP Context). As shown in FIG. 1, in a General Packet Radio Service (GPRS) system, the process of activating the PDP Context, performing data interaction with external Packet Data Network (PDN) and deactivating the PDP Context includes the following steps.
Step 101: A Mobile Station (MS) transmits an Activate PDP Context Request to a Serving GPRS Support Node (SGSN). The Activate PDP Context Request carries the information such as a Network Layer Service Access Point Identifier (NSAPI), a PDP type, an Access Point Name (APN), a demanded Quality of Service (QoS) parameter and a Transaction Identifier (TI). The NSAPI is a component part of a Tunnel Identifier (TID) for identifying the PDP Context between the SGSN and a Gateway GPRS Support Node (GGSN). The PDP type includes a Peer-Peer Protocol (PPP) type, an Internet Protocol (IP) type, etc. The APN can be provided by the MS to the SGSN, the SGSN addresses the corresponding GGSN according to the APN, and the GGSN determines the external network that the MS is to access according to the APN; the MS also may not provide the SGSN with the APN, and the SGSN selects a default APN according to the subscription information of the MS subscriber. The QoS parameter refers to the quality demand, which the packet data service needs to achieve, appointed by the MS. The TI is used by the MS for identifying a certain PDP Context.
Step 102: On receiving the Activate PDP Context Request, the SGSN and the MS perform security checks and encryption. This step is optional.
Step 103: The SGSN resolves address information of the GGSN according to the APN. If the SGSN can resolve the address information of the GGSN according to the APN, the SGSN creates a TEID for the PDP Context; the TEID can be a combination of an International Mobile Subscriber Identity (IMSI) and the NSAPI. And the SGSN transmits a Create PDP Context Request to the GGSN; the Create PDP Context Request carries the PDP type, a PDP address, the APN, the QoS parameters, the TEID, a selection mode and so on. The PDP address can be the IP address of the MS. The PDP address is an optional parameter and may not be carried in the Create PDP Context Request, under which condition, in the subsequent processing steps, the IP addresses can be allocated to the MS by the GGSN or the PDN which finally establishes a connection with the MS. The selection mode refers to the selection mode of the APN, i.e. whether the APN is selected by the MS or the SGSN. If the SGSN cannot resolve the address information of the GGSN according to the APN, the SGSN will reject the Active PDP Context Request initiated by the MS.
Step 104: On receiving the Create PDP Context Request, the GGSN determines the exterior PDN according to the APN, allocates a Charging ID, and starts up the charging process and a QoS negotiation. If the GGSN can meet the QoS demand of the QoS parameter, it will returns to the SGSN a Create PDP Context Response, which carries the information such as the TEID, the PDP address, a Backbone Bearer Protocol, a negotiated QoS parameter and the Charging ID. If the GGSN cannot meet the QoS demand of the QoS parameter, the GGSN will reject the Create PDP Context Request initiated by the SGSN, and then the SGSN will reject the Activate PSP Context Request initiated by the MS.
Step 105: On receiving the Create PDP Context Response, the SGSN inserts the NSAPI and the GGSN address information to identify the PDP Context, selects a radio priority according to the negotiated QoS parameter, and returns an Activate PDP Context Accept to the MS. The Activate PDP Context Accept carries the information such as the PDP type, the PDP address, the TI, the negotiated QoS parameter, the radio priority, PDP configuration options, etc. The SGSN starts up the charging process. The MS establishes a direct routing between the MS and the GGSN after receiving the Activate PDP Context Accept, and the packet data transfer can be performed.
Step 106: The MS performs packet data interaction with the PDN through the SGSN and GGSN.
Step 107: After the packet data interaction, the MS transmits to the SGSN a Deactivate PDP Context Request, which carries the TI.
Step 108: On receiving the Deactivate PDP Context Request, the SGSN performs the security checks and the encryption to the MS. This step is optional.
Step 109-111: The SGSN transmits to the GGSN a Delete PDP Context Request, which carries the TEID. On receiving the Delete PDP Context Request, the GGSN ends the charging process to the MS, deletes the PDP Context corresponding to the TEID, and transmits to the SGSN a Delete PDP Context Response, which carries the TEID. On receiving the Delete PDP Context Response, the SGSN ends the charging process to the MS, deletes the PDP Context corresponding to the TEID, and transmits to the MS a Deactivate PDP Context Response, which carries the TI. On receiving the Deactivate PDP Context Response, the MS deletes the PDP Context corresponding to the TI.
It can be seen from the implementation process described in FIG. 1 that, in the prior GPRS charging system, since the starting point of the charging is set at the moment when the PDP Context is activated, and the ending point of the charging is set at the moment when the PDP Context is deleted, the charging process is performed only according to the data traffic transmitted by the PDP Context, or according to the time span that the PDP Context is in the activation state. However, in practical applications, after the MS and the PDN perform the data interaction, the MS can perform multiple services based on one activated PDP Context. In other words, if the PDN can provide multiple services such as an Email service, a browsing service based on the Wireless Application Protocol (WAP), a file transfer service based on the File Transfer Protocol (FTP) and so on, after the MS and the PDN establish a transfer channel, various services provided by the PDN can be born through one activated PDP Context. However, it is possible that the operators employ different charging methods for different services. For example, for the Email service, the charging can be performed according to times of receiving/sending the Emails; for the WAP browsing service, the charging can be performed according to the traffic; and for the FTP service, the charging also can be performed according to the traffic, but the charging rate of the WAP browsing service is not completely same as the charging rate of the FTP service. In this way, according to the prior GPRS system, the differentiated charging can not be performed to different services born by the same PDP Context at all.
In view of the above, at present, the 3rd Generation Partnership Project (3GPP) is discussing how to realize an IP Flow Based Charging (FBC). For a packet data service, when the subscriber of the MS uses the service, all the transmitted and received IP Flows, or the IP packets, are called a Service Data Flow. In other words, the Service Data Flow is an aggregate composed of multiple IP Flows, so the IP flow based charging can truly reflect the occupation status of the resources by a certain Service Data Flow. The IP Flow based charging can be regarded as the process of respectively filtering the IP Flows of different services born in the same PDP Context through some filters similar to sieves and respectively performing charging to the IP Flows filtered by the different filters, so as to achieve the object of respectively performing charging to the data flows of different services. In this way, the charging granularity according to the IP flow based charging is far smaller than the charging granularity according to the PDP Context based charging. The granularity can be regarded as the size of the sieve apertures; the charging granularity according to the PDP Context based charging is: one PDP Context is one sieve aperture; while the charging granularity according to the IP flow based charging is: one IP Flow is one sieve aperture, i.e. one PDP Context includes multiple sieve apertures. Comparing the charging according to the PDP Context based charging, the charging according to the IP Flow based charging can provide more abundant charging modes for the operators or the service providers.
The system structure, the function demands and the message interaction flow of the FBC are described in 3GPP. A system structure of the FBC supporting online charging is shown in FIG. 2A. Service Control Point (SCP) 201 of Customized Application for Mobile Network Enhanced Logic (CAMEL) and Service Data Flow Based Credit Control Function (CCF) 202 compose Online Charging System (OCS) 206. CCF 202 intercommunicates with Service Data Flow Based Charging Rule Function (CRF) 203 through an Ry interface, CRF 203 intercommunicates with Application Function (AF) 204 through an Rx interface, CRF 203 intercommunicates with Traffic Plane Function (TPF) 205 through a Gx interface, and CCF 202 intercommunicates with TPF 205 through a Gy interface.
A system structure of the FBC supporting offline charging is shown in FIG. 2B. CRF 203 intercommunicates with AF 204 through a Rx interface, CRF 203 intercommunicates with TPF 205 through a Gx interface, and TFP 205 respectively intercommunicates with Charging Gateway Function (CGF) 207 and Charging Collection Function (CCF) 208 through a Gz interface.
TPF 205 bears the IP Flows. When the bearer of the IP Flows is established, TPF 205 transmits a Request Charging Rules to CRF 203 through the Gx interface, and the Request Charging Rules carries information relevant to the subscriber and the MS, bearer characteristics and information relevant to the network. The information relevant to the subscriber and the MS can be a Mobile Station International ISDN (MSISDN) Number or an International Mobile Subscriber Identifier (IMSI) etc; the information relevant to the network can be a Mobile Network Code (MNC) or a Mobile Country Code (MCC) etc. In addition, the bearer will be modified during the transmission process of the IP Flows, for example, performing a re-negotiation to the QoS parameters; and when the QoS parameters of the same service used by the subscriber are different, it is possible that the charging rules are different, e.g. if the QoS parameters are decreased, the corresponding rate will be decreased. Here, when the bearer is modified, TPF 205 can transmit the Request Charging Rules to CRF 203 again to request a new charging rule; CRF 203 selects a proper charging rule according to the above-mentioned information provided by TPF 205 and returns the selected charging rule to TPF 205. The charging rule includes the information such as a charging mechanism, a charging type, a charging key, a Service Data Flow filter, a charging rule priority and so on. The charging mechanism can be the online charging or the offline charging; the charging type can be the time span based charging or on the data traffic based charging; the charging key is a parameter relevant to the charging rate, CRF 203 may not directly provide TPF 205 with the charging rate, but only provide TPF 205 with the parameters relevant to the charging rate; the Service Data Flow filter is used for indicating TPF 205 to filter the IP Flows, and then TPF 205 will perform charging to the filtered IP Flows according to the charging rule. The Service Data Flow filter can include an IP five-tuple, and the IP five-tuple can include the information of the source/destination IP address, the source/destination Port Number, and the Protocol ID) etc. For example, CRF 203 indicates TPF 205 to filter the IP Flow with the source address of 10.0.0.1, the destination address of 10.0.0.2, the source Port Number of 20, the destination Port Number of 20 and the protocol type of TCP, and performs charging to the filtered IP Flow according to the charging rule.
CRF 203 can provide TPF 205 with an Event Trigger to make TPF 205 to ask for a new charging rule from CRF 203 when a specific event occurs. For example, CRF 203 requests TPF 205 to ask for a new charging rule from CRF 203 when the event of some certain bearers being modified occurs.
Besides selecting the proper charging rule according to the input information provided by TPF 205, CRF 203 also can select proper charging rule according to the input information of AF 204 or OCS 206. For example, AF 204 notifies CRF 203 of the service type currently used by the subscriber, and CRF 203 will select the corresponding charging rule according to the service type.
OCS 206 is composed of two functional entities: SCP 201 and Service Data Flow Based Credit Control Function (CCF) 202. CCF 202 is a functional entity used for carrying out credit control, and is only applied in online charging systems; CCF 202 can be realized by adding a new function in the existing OCS 206. During an online charging process, CCF 202 is used for performing management and control to the credit of the subscriber, when the subscriber uses a certain service, CCF 202 performs authentication to the credit in the credit pool of the subscriber, and dispatches the credit, which can be used by the subscriber, to TPF 205 through the Gy interface.
Corresponding to the GPRS network, TPF 205 is a GGSN, AF is a service gateway or a service server in the PDN and CRF 203 is a new-added logic entity. TPF 205 is an enforcement point of the charging rule, and CRF 203 is a control point of the charging rule.
At present, the criterion defines that the communication between the CRF and the TPF is performed by means of Diameter sessions, and different Diameter sessions are identified by different Diameter session identifiers. When the bearers are established, the TPF requests the charging rules from the CRF, and the CRF provides the TPF with the charging rules; at this time, a Diameter session between the CRF and the CRF is established and identified by a Diameter session identifier. During the subsequent process of modifying the bearer and deleting the bearer, when the TPF needs to request a charging rule again from the CRF, the TPF uses the Diameter session identifier to identify the mapping relationship between the current Request Charging Rules and the formerly established Diameter session; in a similar way, when the CRF receives the input information used for determining the charging rule provided by the AF or the OCS and needs to provide the TPF with the charging rule on its own initiative, the CRF also needs to use the Diameter session identifier to identify the mapping relationship between the currently provided charging rule and the formerly established Diameter session.
The significance of establishing the Diameter session between the two entities is to establish a State Machine between the two entities, in this way, the two entities can directly use the data in the State Machine when they perform the subsequent interactions, and do not need to provide the relevant information every time they interact. For example, when the bearer is established, the TPF needs to provide some relevant information such as the subscriber information, the bearer properties and the network information; after establishing a Diameter session between the TPF and the CRF, both the TPF and the CRF will store the relational information; during the subsequent interaction process between the TPF and the CRF, such as the TPF requesting charging rule from the CRF while modifying the bearer or deleting the bearer, the OCS and AF providing the CRF with the input information to determine the charging rule, and the CRF transmitting the information such as the charging rule on its own initiative. The transmitter does not need to provide the relevant information to the receiver, but only provides the Diameter session identifier identifying the corresponding Diameter session.
Although the criterion defines that the communication between the CRF and the TPF can be performed by means of Diameter sessions, but the criterion does not indicate the method for establishing the Diameter session.